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SCIENCE  OF  INTEGRATION 


INTRODUCTION 

The  design  of  complex,  human-operated  (man-machine)  systems,  especially 
when  these  systems  are  subject  to  evolutionary  change  Including  add-on  func¬ 
tions,  tasks, and  hardware,  presents  a  number  of  challenges  to  the  design/ 
management  team.  Without  "good  engineering"  and  established  procedures  to 
control  the  engineering  function,  the  design  process  can  break  down  in  a 
number  of  ways.  With  respect  to  function  the  continual  addition  of  new 
functions  may  result  In  redundancy.  Incompatibility,  or  excessive  complexity 
with  Its  concomitant  high  cost  and  reduced  reliability.  The  addition  of 
operator  tasks  may  result  In  an  excessive  overall  burden  on  the  operator, 
tasks  that  Interfere  with  each  other,  or  tasks  that  either  cannot  be  per¬ 
formed  or  cannot  be  performed  correctly  under  real  operational  conditions. 
Hardware  problems  can  Include  excessive  weight,  excessive  bulk,  excessive 
power  consumption  or  heat  dissipation,  direct  Interference' between  separate 
hardware  functions,  and  problems  with  reliability  and  maintainability. - 

Many  of  these  problems  have  been  observed  In  the  development  of  Air 
Force  life  support  and  protective  equipment.  In  the  past  each  piece  of 
equipment  has  often  been  developed  Independently,  usually  by  different 
companies,  and  over  different  periods  of  time.  Thus  the  existing  system  is 
a  composite  of  "quick- fix"  and  "add-on"  approaches  to  overall  system  develop¬ 
ment.  As  a  result,  systems  are  complicated,  costly,  bulky,  weighty,  and,1n 
many  cases, aircraft  specific.  These  systems  can  adversely  affect  pilot  per¬ 
formance  and  safety,  can  be  a  logistical  nightmare,  have  high  life  cycle 
costs,  and  have  less  than  optimal  reliability  and  maintainability.  Further¬ 
more,  these  systems  are  not  presently  fixed, and  the  processes  by  which  they 
arrived  at  their  current  status  threaten  to  continue  to  produce  add-ons 
which  may  have  detrimental  overall  Impact. 

Recognition  of  this  continuing  problem  was  the  motivation  for  this 
research  project  with  the  main  objective  to  Identify,  under  the  term  "inte¬ 
gration,"  those  rules,  guidelines,  and  management  processes  that  when  fol¬ 
lowed  would  result  In  Improved  system  performance  and  avoidance  of  the 
problems. 

Consistent  with  the  objective  of  the  research,  a  review  of  the  available 
literature  and  current  practice  was  made  under  the  headings  of  "systems"  and 
"Integration."  It  Is  noteworthy  that  despite  the  widespread  use  of  t|ie  terms 
"system"  and  "Integration"  little  relevant  literature  was  found.  -  In  fact, 
the  terms  are  now  so  wfdely  used  for  such  a  broad  spectrum  of  subjects  that 
they  have  become  totally  ambiguous.  As  used  here,  system  will  mean  a  col¬ 
lection  of  interrelated  components  unified  by  design  to  obtain  one  or  more 
objectives.  Subsystem  will  denote  a  part  of  the  system  which  Is  separately 
Identifiable  by  function,  design,  or  both.  The  interrelated  parts  of  a  sys¬ 
tem  can  be  considered  by  definition  to  be  at  least  Interfaced;  that  Is,  they 
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are  connected  together  In  some  way  such  that  the  collection  exists  as  an 
Identifiable  set.  Beyond  such  Interfacing  It  Is  desirable.  If  not  essential, 
that  the  system  be  Integrated  (to  be  defined  later). 

Parallel  to  the  literature  review  an  effort  was  made  to  contact  other 
Industries  and  agencies  that  were  perceived  to  have  analogous  problems  and 
to  ask  them  what  guidelines  they  had,  written  or  otherwise,  in  this  area. 
Again  there  turned  out  to  be  a  dearth  of  useful  Information,  even  from  organ¬ 
izations  that  had  “Integration"  as  part  of  a  group  or  job  title.  Typical 
responses  ranged  from  “good  luck"  to  "It's  just  good  engineering."  The 
closest  thing  to  what  was  sought  was  configuration  control,  but  that  is 
concerned  with  management  and  paper  flow  rather  than  engineering  achievement. 

With  the  failure  of  the  traditional  resources  of  published  literature 
and  personal  contact,  and  having  a  problem  which  was  not  amenable  to  an  ex¬ 
perimental  or  analytical  attack,  the  only  remaining  approach  was  one  of  indi¬ 
vidual  and  group  contemplation. 

Since  the  problems  Identified  here,  and  the  proposition  that  integration 
will  address  these  problems,  are  Issues  in  engineering  design,  a  review  of 
aspects  of  the  engineering  design  process  is  necessary.  This  review  will  be 
followed  by  a  definition  and  discussion  of  Integration. 


DESIGN 

The  engineering  design  process  always  begins  with  a  set  of  objectives 
which  the  proposed  design  must  achieve.  These  objectives  must  consist  of 
two  major  parts.  The  first  part  is  the  function  or  functions  that  the  resul¬ 
tant  system  or  subsystem  must  achieve.  The  second  part  is  the  constraints 
on  the  system.  Physical  constraints  may  Include  weight,  size,  power  require¬ 
ments,  heat  dissipation,  etc.  For  man-machine  systems  additional  constraints 
may  be  in  the  form  of  the  number  and  kinds  of  tasks  that  can  be  placed  on  the 
operator.  These  task  constraints  may  relate  to  the  number  and  kinds  of  other 
tasks  that  the  operator  may  also  need  to  perform  and/or  the  ability  of  the 
operator  to  perform  tasks  under  real  operational  conditions.  Other  con¬ 
straints  may  result  from  the  conditions  of  use  of  the  system.  Additional 
constraints  are  In  the  form  of  reliability  and  maintainability  considera¬ 
tions,  and,  of  course,  cost  Is  commonly  also  a  constraint. 


Function 

The  functional  requirements  can  generally  be  considered  as  absolutes; 
that  Is,  the  system  must  be  able  to  perform  the  stated  function.  It  cannot 
partly  perform  the  function  nor  Is  It  necessarily  required  to  perform  more 
than  the  required  function.  However,  functional  requirements  should  at  times 
be  open  to  review  with  respect  to  reasonableness  of  the  function  and  feasi¬ 
bility  of  Its  achievement  under  the  given  system  constraints. 

An  example  here  might  be  a  requirement  for  head  Impact  protection. 
Assuming  the  requirement  Is  rational,  the  design  must  achieve  the  desired 
degree  of  protection.  A  lesser  degree  of  protection  Is  not  acceptable  and 


would  represent  a  failure  of  the  design  to  achieve  the  stated  goals.  A  great¬ 
er  level  of  protection  might  be  desirable  but  would  probably  Involve  more 
weight  or  bulk  than  necessary  to  achieve  the  required  protection, and  there¬ 
fore  it  way  be  more  desirable  to  reduce  the  weight  or  bulk  rather  than  pro¬ 
vide  the  overdesigned  system.  If  the  functional  requirement  Is  not  feasible 
within  the  design  constraints,  then  either  the  functional  requirement  or  the 
constraint  must  be  subjected  to  further  review.  It  must  be  noted  here  that 
feasibility  may  be  a  function  of  the  talents  of  the  design  team;  l.e. ,  what 
Is  Infeasible  for  one  group  may  be  feasible  for  another. 

With  complex  systems  the  performance  of  each  and  every  function  must  be 
assured  such  that  the  functions  are  not  only  achieved  Independently  but  are 
also  achieved  sequentially  or  simultaneously  as  required.  Furthermore,  they 
must  function  under  the  real  operational  conditions.  Thus  the  design  of  an 
ejection  seat  release  mechanism  which  requires  the  operator  to  activate  a 
particular  control  may  appear  to  meet  the  narrowly  defined  requirements  of 
the  release  mechanism  itself.  However,  If  under  real  conditions  the  opera¬ 
tor's  hands  are  engaged  In  other  tasks  when  the  need  for  ejecting  occurs,  or 
if  the  operator  cannot  move  his  hand  to  activate  the  control  under  certain  condi¬ 
tions,  then  the  design  of  the  ejection  seat  release  mechanism  is  unaccep¬ 
table,  at  least  for  some  operational  requirements.  The  other  activities 
which  the  operator  may  be  engaged  in  and  the  existence  of  G  forces  which 
Interfere  with  the  operator's  performance  represent  constraints  on  the  system 
and  subsystem  design  that  should  have  been  accounted  for  in  the  ejection  seat 
release  mechanism  design  constraints. 


Constraints 

All  design  projects  are  subject  to  constraints  of  various  kinds.  Some 
of  these  constraints  may  take  the  form  of  limits  (maximums  or  ralnlmums) 
rather  than  the  absolute  form  of  the  functional  requirements.  Thus  a  helmet 
for  head  protection  may  be  limited  to  a  certain  weight, and  therefore  the 
resultant  design  must  weigh  no  more  than  the  specified  amount.  A  helmet 
which  achieves  the  functional  protection  requirement  but  weighs  more  than  the 
specified  weight  Is  not  an  acceptable  design.  In  this  case  the  helmet  must 
be  redesigned  or  the  weight  limit  reopened  for  further  consideration.  Other 
limit  constraints  may  be  In  physical  factors  such  as  size,  thermal,  or 
acoustic  characteristics.  Reliability  and  maintainability  can  also  be  ex¬ 
pressed  In  the  form  of  limiting  values. 

Task  constraints  are  of  great  Importance  in  the  design  of  complex  man- 
machine  systems.  It  must  be  known  In  advance  what  the  system  operator  Is 
capable  of  achieving  In  terms  of  level  of  performance,  duration  of  perfor¬ 
mance,  reliability  of  performance,  etc.,  with  respect  to  all  tasks  which  must 
be  performed.  It  must  also  be  known  what  Influences  operator  capability  and 
performance  such  as  conditioning,  training,  stress,  and  perceived  comfort. 

In  the  case  of  aircrew  systems  the  conditions  of  actual  use  of  the  sys¬ 
tem  are  of  critical  Importance.  It  Is  therefore  necessary  for  the  designer 
to  have  knowledge  In  the  form  of  complete  scenarios  of  what  is  taking  place 
In  the  environment  prior  to  or  during  the  time  when  a  system  function  or 


operator  task  performance  is  to  occur.  Environmental  influences  may  include 
acceleration,  vibration,  temperature,  light  level,  chemicals,  fire,  equipment 
malfunctions,  and  ultimately  enemy  attack.  Clearly  any  design  which  results 
in  a  system  or  subsystem  whose  functional  capability  is  such  that  it  works 
when  tested  under  unrealistic  mock  or  simulated  conditions  but  fails  to  func¬ 
tion  under  operational  conditions  is  an  unacceptable  design  which  has  not  met 
what  should  have  been  correctly  stated  design  requirements. 

In  some  cases  it  may  be  possible  to  achieve  a  design  that  meets  the 
functional  requirements,  physical  and  task  constraints,  but  only  under  a  sub¬ 
set  of  the  possible  operational  environments.  Such  a  design  is  at  the  onset 
unacceptable  but  it  may  be  appropriate  to  accept  the  design  with  the  under¬ 
standing  that  it  does  not  meet  the  original  design  objectives.  This  approach 
can  be  looked  at  as  either  a  restatement  of  the  constraints  so  as  to  allow 
the  design  to  conform  or  as  an  acceptable  exception  to  conformity.  The 
former  procedure  is  dangerous  in  that  if  the  original  constraints  were  ra¬ 
tional,  downgrading  them  may  be  questionable.  In  the  latter  case  the  re¬ 
strictions  on  acceptable  ranges  of  utility  will  have  to  be  "remembered,"  and 
if  this  approach  is  allowed,  it  is  conceivable  that  many  of  the  subsystems 
will  have  different  regions  of  acceptable  performance.  Serious  management 
and  operational  difficulties  may  result. 


Information  Availability 

Rational  design  requires  the  availability  of  a  complete  statement  of  all 
functional  requirements  or  a  correctly  isolated  statement  of  a  single  func¬ 
tional  requirement.  It  also  requires  a  complete  statement  of  both  physical 
and  task/operator  constraints.  And  finally,  the  requirements  and  constraints 
must  be  put  in  the  context  of  actual  conditions  of  use.  Some  of  this  infor¬ 
mation  may  not  always  be  available  and  may  be  subject  to  ongoing  research  or 
provide  the  basis  for  new  research  directions.  Where  adequate  knowledge  is 
lacking,  it  may  be  appropriate  where  possible  to  identify  those  aspects  of 
the  system  constraints  that  are  unknown  and  likewise  to  identify  those 
aspects  of  a  resultant  design  that  may  be  inadequate  under  conditions  that 
have  not  yet  been  properly  identified.  This  identification  can  be  especially 
Important  In  systems  subject  to  evolutionary  or  add-on  design  where  the 
system  at  any  point  in  time  may  Include  both  proven  and  unproven  designs  and 
In  which  the  addition  of  new  functions,  tasks,  or  components  may  exacerbate 
the  limitations  of  the  existing  system. 

Unknown  aspects  of  the  operational  environment  also  present  serious 
limitations  to  the  probable  success  of  aircrew  systems.  In  particular,  when 
operational  requirements  change,  there  should  not  be  automatic  expectation 
that  the  existing  system  will  continue  to  perform  or  that  a  few  quick  fixes 
or  add-ons  will  be  adequate  to  account  for  the  effect  of  the  changed  opera¬ 
tional  environment  on  system  and  operator  performance. 


Add-on  vs  From-Scratch  Design 

Two  design  approaches  are  relevant  to  the  present  discussion.  In  one 
design  approach  the  work  begins  without  constraints  due  to  previously 


'%Xltt1ng'  hanfrttre;  tftat  Is,  the  design  proceeds  "from  scratch."  In  the  case 
df  a^^reit  Hfe  support  equipment  this  approach  could  mean  either  without 
'tonftral  rtfs'  due  to  the  existing  aircrew  worn  or  operated  equipment,  or  in  an 
even  broader  sense,  the  design  could  proceed  without  the  constraints  of  the 
existing  cockpit  and  aircraft-mounted  equipment;  that  is,  the  cockpit  system 
/we^e; .be  designed  simultaneously  with  the  aircrew  equipment. 

p  from  scratch  presents  a  broad  opportunity  to  continually  produce 
■'t ilhich  meets  the  Overall  functional  and  constraint  criteria.  It  does 
not,,  however,  insure  that  the  design  wi  1 1  achieve  total  success.  Depending 
on  the  scale  of  the  system  the  control  of  such  a  design  approach  can  be  very 
difficult  due  to  the  scope  of  the  work  and  the  number  of  designers  needed. 

The  somewhat  unfortunate  response  to  this  challenge  is  to  subdivide  the  total 
;/:*|tSigi  project  into  smaller  units.  This  kind  of  modularization  apparently 
allows  redefinition  of  the  design  problem  into  more  workable  units.  To  be 
effective,  this  redefinition  process  requires  distribution  of  system  con- 
Stff Into  and  other  design  criteria,  and  the. establishment  of  interfacing 
t^uifbfcBhtoi  These  Interfacing  requirements  can  be  as  simple  as  the  loca¬ 
tion  intf  size  of  boTt  holes  or  the  type  of  electrical  connector  to  be -employed. 
Th«y  cart  also  involve  communication  ami  coordination  requirements  for 
betoeen-m^le  functions  tod  operator/module  Interactions.  Such  a  modular¬ 
ized  system  may  superficially  look  welt  designed,  but  It  may  not  result  In 
an  optimization  of  the  total  package.  For  example,  a  number  of  units  may 
.  hams  batteries  whereas  an  alternative  design  may  have  allowed  a  single  bat¬ 
tery  (iith  appropriate  considerations  of  redundancy).  A  modularized  system 
may  result  in  one  module  which  needs  to  be  heated  while  another  module  needs 
tobd  tdoled.  In  an  alternative  design  it  might  have  been  possible  to  couple 
thtoe  requirements.  Furthermore  It  is  possible  that  two  or  more  separately 
designed  modules  will  riot  be  CdrreCtTy  operable  simultaneously,  even  though 
etch  meets  its  own  design  requirements.  In  this  case  the  problem  may  have 
been  caused  by  the  original  breakout  of  the  design  requirements  Into  modular 

••  d;teft  su2  sdular  inter- 

rertnce  arte  reject  the  design  package.  Thus  such  a  design  should  never  go 
into  service,  and  if  it  does,  It  represents  a  breakdown  In  the  speclflcatlon- 
«!tg»*-«cceptance  tqst  sequence. 

When  additional  or  modified  equipment  becomes  necessary  and  appropriate 
. °f .ftofeTC^  and .  jmrelopment  efforts,  design  from  scratch  would 
reqk^e  tMfrjN  ^isttog  system  be  abandoned  and  a  new  System  designed  which 
ifi£$itodr?tos  the  irfsfirtg  and  toe  new  technology.  The  degree  of  redesign  and 
abandonmtot  would,  of  course,  depend  on  the  complexity  and  overall  impact  of 
the  new  devices.  Two  noteworthy  exceptions  to  abandon/redesign  are  when  a 
ISf  *:*p1acfs  *n  old  subsystem  or  when  the  existing  design 

S2  WyNMjr  allowed  for  the  addition  of  the  new  equipment.  However,  In 
***  Jdtal  pursult  of  the  deslgn-from-scratch  approach,  total  redesign  must  be 
considered. 

^  kJJL  23  !!?!!£ J  ch  existing  equipment  is  accepted  as  a  given 

®r/  new  equipment  which  will  be  added  to  the 

feting  configuration.  This -approach  carries  with  It  the  necessity  of 
interfacing  the  new  equipment  with  the  old.  This  kind  of  Interfacing  Is  much 


more  likely  to  produce  a  total  equipment  package  that  is  unwieldy,  that  ap¬ 
proaches  or  exceeds  overall  system  constraints,  and  that  is  at  least  partial¬ 
ly  Inoperable  with  respect  to  simultaneous  use  of  its  subsystems  or  its  use 
in  some  operational  environments.  However,  here  also  an  appropriate  test 
program  should  prevent  such  designs  from  becoming  operational. 

Despite  the  inherent  limitations  In  add-on  design  it  is,  of  course, 
attractive  from  the  viewpoints  of  cost  and  convenience.  Add-on  design  is 
also  consistent  with  ongoing  research  and  development  efforts  through  which 
new  subsystems  are  continually  evolving.  When  such  a  subsystem  reaches  the 
stage  at  which  It  should  be  implemented  in  the  operational  system,  adding  it 
to  the  existing  system  may  appear  to  be  more  desirable  than  redesigning  the 
existing  system  in  order  to  accommodate  the  new  equipment.  The  alternative 
would  be  either  a  total  redesign  as  each  new  subsystem  became  available  or 
the  holding  of  new  subsystems  until  their  Individual  or  collective  importance 
warranted  a  total  redesign.  Under  either  of  these  alternatives  actual  add¬ 
ons  would  effectively  be  forbidden. 

It  Is  likely,  however,  that  add-on  design  will  continue  to  be  an  attrac¬ 
tive  approach  and  It  would  therefore  be  desirable  to  improve  add-on  design 
procedures  In  order  to  maximize  their  effectiveness. 

Add-on  design  requires  all  of  the  predesign  information  outlined  previ¬ 
ously.  Of  particular  Importance  is: 

•Clear  definition  of  overall  system  constraints  and  translation  of  these 
constraints  into  constraints  on  the  add-on. 

•Complete  operational  scenarios  which  can  be  used  to  test  for  equipment/ 
equipment  and/or  equipment/ opera tor  Interference. 

Additional  requirements  are: 

•Management  structures  and  authority  which  can  assure  compliance  with 
overall  system  requirements. 

•Management  structure  and  authority  which  can  reject  the  add-on,  hold  the 
add-on,  and/or  declare  that  total  redesign  has  become  necessary. 

•The  cumulative  effect  of  add-ons  must  be  monitored  so  that  each  addi¬ 
tional  add-on  can  be  assessed  with  respect  to  the  then  current  system. 

The  appropriate  management  structures  not  only  must  exist  as  bureau¬ 
cratic  entitles  but  also  must  be  effective.  Effectiveness  is  largely  depen¬ 
dent  on  two  factors:  the  quality  of  the  personnel  involved  and  the  explicit¬ 
ness  of  the  rules  governing  their  activity. 

It  should  also  be  noted  that  the  simultaneous  consideration  of  two  or 
more  add-ons  can  be  especially  dangerous  with  respect  to  correct  assessment 
of  their  overall  and  Interactive  effects.  Add-ons  should  therefore  be  con¬ 
sidered  sequentially.  It  Is  also  appropriate  to  anticipate  what  new  devices 
are  In  the  research  and  development  stream  which  will  effect  or  interact  with 
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a  subsystem  currently  ready  or  nearly  ready  for  Inclusion  ’"n  the  operational 
package.  The  opportunity  may  occur  to  combine  these  design  projects  In  the 
final  stages  of  their  development. 


Design  Alternatives 

Me  have  described  In  general  form  the  spectrum  of  Information  required 
for  a  system  design  task  which  Includes  all  of  the  functional  requirements 
and  all  of  the  constraints  on  the  system.  For  simplicity  In  the  following 
discussion  It  will  be  assumed  that  whether  a  design  has  achieved  a  function 
can  be  answered  either  yes  or  no,  and  perhaps  more  Importantly  whether  the 
design  has  achieved  all  functions  can  also  be  answered  yes  or  no.  The  system 
constraints  of  Interest  will  be  assumed  to  be  In  the  form  of  limits,  e.g., 
maximum  weight.  Furthermore,  the  operational  environment  and  an  appropriate 
test  program  will  be  assumed  to  be  known. 

It  Is  recognized  in  engineering  that  there  are  almost  always  several  or 
many  alternative  designs  for  a  system.  Although  each  design  may  be  accep¬ 
table,  the  classic  thought  process  Is  then  one  of  choice  between  design  al¬ 
ternatives,  or  in  a  more  theoretical  sense  the  optimization  of  the  design 
with  respect  to  one  or  more  of  the  design  objectives.  ("Optimization"  will 
be  used  here  to  mean  "improved"  or  "better"  as  well  as  "optimum".)  Since  it 
is  assumed  here  that  functional  achievement  is  a  yes/no  parameter,  such  opti¬ 
mization  would  only  be  amongst  designs  which  achieve  the  functional  require¬ 
ments.  Furthermore,  at  this  point  only  optimization  from  acceptable  designs 
will  be  considered;  l.e.,  all  of  the  candidate  designs  also  meet  all  of  the 
system  constraints  and  are  fully  functional  under  all  operating  conditions. 

Under  these  circumstances  the  only  thing  left  with  respect  to  optimiza¬ 
tion  are  those  constraints  posed  in  the  form  of  a  limit.  For  example.  If 
system  A  and  system  B  both  perform  the  required  task  and  the  maximum  weight 
allowed  Is  10  pounds  and  system  A  weighs  6  pounds  while  system  B  weighs  8 
pounds,  then  system  A  is  chosen  under  the  assumption  that  the  lowest  weight 
system  is  the  more  desirable. 

In  complex  designs  there  may  be  many  limit- type  constraint  parameters, 
and  therefore  the  optimization  question  becomes  one  of  what  to  optimize  with 
respect  to~e1ther  singly  or  in  combination.  For  example,  if  system  A  and  sys¬ 
tem  B  above  have  respective  reliabilities  of  .91  and  .96  (compared  to  a  mini¬ 
mum  of  .90),  it  is  now  necessary  to  decide  if  weight  or  reliability  is  the 
more  Important  parameter.  Adding  cost,  maintainability,  and  any  number  of 
other  such  parameters  further  complicates  the  decision-making  process.  It  is 
recognized  that  optimization  is  most  likely  to  involve  tradeoffs  since  the 
lightest  system  Is  not  necessarily  going  to  be  the  most  reliable,  or  the 
least  expensive,  or  the  most  durable.  In  general,  therefore,  the  relative 
Importance  of  each  parameter  requires  a  subjective  judgment.  In  fact,  modern 
decision  theory  tends  to  look  not  for  the  "best"  design  but  for  the  range  of 
acceptable  alternatives  (and  the  probability  of  avoiding  unacceptable  alter¬ 
natives). 
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INTEGRATED  SYSTEMS 

As  discussed,  the  design  process  has  been  pursued  to  the  point  where 
choices  need  to  be  made  between  alternative  designs  so  as  to  select  that 
design  which  optimizes  the  adherence  to  system  constraints,  it  having  been 
assumed  that  we  are  only  interested  in  those  designs  which  are  fully  func¬ 
tional  and  within  the  constraint  limits. 

Many  choices  in  the  engineering  armamentarium  exist  for  alternative 
designs  which  would  have  differing  weights,  reliabilities,  etc.  Of  these, 
the  concept  of  interest  is  that  of  integration  which  will  now  be  defined  as 
the  process  of  combining  tasks  and/c**  hardware  so  as  to  optimize  a  system 
design  with  respect  to  one  or  a  combination  of  pre-selected  constraints. 

Thus  an  integrated  system  will  be  a  system  in  which  tasks  and/or  hardware 
have  been  combined  so  as  to  achieve  the  required  optimization. 

Task  Integration 

Task  integration  is  defined  as  combining  or  eliminating  operator  tasks 
in  a  man-machine  system  so  as  to,  in  general,  simplify  or  combine  the  re¬ 
quirements  placed  on  the  operator  such  that  the  tasks  can  be  achieved  within 
the  operator's  short-  and  long-term  capabilities.  Tasks  can  be  altered  or 
eliminated  by  changing  the  hardware  configuration  of  the  system.  For  exam¬ 
ple,  if  an  ejection  seat  release  mechanism  is  acceptable  but  difficult  for 
the  operator  to  activate,  then  a  hardware  change  which  alters  the  location 
of  the  activator,  the  type  of  button  or  handle,  or  the  force  required  on  the 
activator  would  be  considered  an  example  of  integrating  the  task  requirement 
with  the  capabilities  of  the  human  operator.  In  this  case  optimization  (or 
improvement)  would  be  achieved  with  respect  to  a  parametric  measure  of  oper¬ 
ator  performance.  If  the  activator  had  been  inoperable  in  its  present  loca¬ 
tion,  the  design  should  be  rejected.  Here  the  design  could  be  brought  into 
compliance  by  relocating  the  control  to  a  position  more  compatible  with 
operator  performance. 

Tasks  can  be  performed  with  the  hands,  feet,  voice,  body  movements,  eye 
position,  and  perhaps  thought  processes.  Thus  changing  the  body  system  which 
is  used  to  perform  a  task  so  as  to  improve  operator  performance  would  also  be 
included  under  task  Integration.  In  some  cases  multiple  tasks  and  controls 
can  be  combined  into  a  single  device.  For  example,  a  joy  stick  can  provide 
many  functional  Inputs  to  the  system  which  would  otherwise  require  multiple 
body  segments  and  hardware  Interfaces. 

Communication  from  the  machine  to  the  operator  can  also  use  the  tradi¬ 
tional  tactile,  auditory,  and  visual  senses  as  well  as  possibly  taste  and 
smell.  Thus  changing  the  sensory  input  to  the  operator  can  also  improve 
operator  performance. 

The  sequence  and  duration  of  tasks  can  be  as  critical  as  their  indivi¬ 
dual  performance.  Thus  altering  when  a  task  must  be  performed  with  respect 
to  all  other  tasks  will  be  considered  a  form  of  task  integration  or  combina¬ 
tion. 
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Unfortunately  there  is  no  simple  answer  to  the  operator  input/output 
problem  that  automatically  provides  the  optimum  operator  performance;  however, 
numerous  guidelines  to  enhancing  operator  performance  fall  under  the  general 
rubric  of  human  factors.  As  in  many  areas  of  engineering  endeavor,  there  is 
still  much  which  is  not  known  about  human  factors  and  there  is  considerable 
ongoing  research  to  further  define  the  enhancement  of  operator  performance. 
Pending  further  progress  in  this  area  design  alternative  selection  Is  pre¬ 
sently  limited  to  conformance  with  reasonably  agreed  upon  guidelines  and  to 
explicit  realistic  testing  of  designs  against  quantifiable  performance  mea¬ 
sures.  Such  testing  is  necessary  to  eliminate  unacceptable  designs  as  well 
as  to  choose  between  acceptable  ones. 


Hardware  Integration 

Hardware  integration  concerns  the  actual  physical  components  of  the  sys¬ 
tem  and  subsystems.  Here  appropriate  combinations  can  be  achievable  in 
terms  of  both  the  controls  presented  to  the  operator  and  the  more  internal 
parts  of  the  system.  Such  combinations  may  serve  to  decrease  the  number  of 
components  and  thereby  decrease  weight  and  Improve  overall  system  reliability. 
However,  system  reliability  could  also  be  decreased  in  the  sense  that  if  a 
multifunctional  subsystem  does  fail,  it  would  eliminate  more  functions  than 
if  a  more  independent  subsystem  failed.  Thus  the  higher  the  level  of  combi¬ 
nation  or  Integration,  the  less  chance  there  may  be  of  failure  but  if  a 
failure  occurs,  the  greater  would  be  the  consequences. 

Modern  electronics  serves  to  Illustrate  aspects  of  the  physical  integra¬ 
tion  of  hardware  components  since  one  aspect  of  the  recent  history  of  modern 
electronics  is  that  the  basic  building  block,  the  chip,  has  become  more 
complex  with  each  generation  such  that  the  number  of  functions  of  a  single 
unit  have  rapidly  increased.  The  acronym  VLSI  as  applied  to  current  chips 
stands  for  Very  Large  Scale  Integration.  This  trend  and  achievement  repre¬ 
sent  exactly  the  kind  of  Integration  that  Is  of  interest  here. 

Given  a  specific  set  of  functional  requirements  at  any  given  point  in 
time,  a  number  of  electronic  components  could  be  assembled  from  those  avail¬ 
able  and  they  would  be  Interconnected  so  as  to  achieve  the  desired  function. 
Some  of  the  components  might  be  Interconnected  in  a  very  interactive  way, 
i.e.,  be  part  of  a  single  circuit  element  which  might  be  called  a  module. 
Other  modules  might  also  exist  in  which  other  components  form  the  circuit. 
These  modules  could  then  be  Interconnected  as  necessary  to  achieve  the  whole 
design.  In  this  kind  of  design  If  a  new  function  were  added  to  the  list  of 
requirements  two  approaches  would  be  possible.  One  would  be  to  add  a  new 
module  that  provided  the  new  function.  The  second  would  be  to  add  to  or 
modify  one  of  the  existing  modules.  If  possibly  to  combine  the  new  function 
with  the  old. 

True  Integration  is  achieved  when  the  design  becomes  fixed  and  technical 
and  economic  feasibility  dictate  that  the  entire  system  will  be  replaced  by 
only  a  few  chips  or  perhaps  one  chip  that  does  all  of  the  things  that  the 
existing  assemblage  of  components  did.  Such  a  new  chip  once  made  may  be 
unsuitable  for  further  add-ons,  or  may  Itself  be  designed  such  that  new 


or  altered  requirements  could  be  easily  achieved  without  disrupting  the  inte¬ 
gration.  The  concept,  and  reality,  of  changing  a  device  by  changing  only  its 
memory  of  the  function  to  be  performed,  is  an  excellent  example  of  integrated 
and  yet  flexible  design. 

In  comparing  the  new  single  chip  design  to  the  old  multiple  component 
design,  a  number  of  tradeoffs  may  occur.  The  new  system  is  undoubtedly 
smaller  and  lighter  and  probably  consumes  less  power  and  dissipates  less  heat 
It  is,  however,  essentially  unrepairable  except  by  replacement,  although  re¬ 
placement  would  be  an  easy  matter.  Furthermore, total  system  redundancy  could 
be  easily  provided. 

Although  unrepairable,  the  new  chip  would  tend  to  be  more  reliable,  once 
past  its  early  development,  than  the  many  components  used  before.  However, 
if  it  failed,  it  is  probably  more  likely  that  the  entire  system  will  malfunc¬ 
tion  whereas  in  the  component/module  design  continued  function  of  some  parts 
of  the  system  may  be  possible  despite  a  partial  failure. 

The  single  chip  may  be  more  inflexible  with  respect  to  new  requirements 
than  the  multiple  component/modular  device.  If,  in  fact,  new  functions  are 
necessary,  the  chip  may  have  to  be  discarded  and  a  new  one  designed.  Alter¬ 
nately  new  components  could  be  added  to  the  master  chip  and  a  mixed  design 
allowed  to  evolve.  Modern  electronics  should  serve  the  system  designer  as  a 
model  of  the  achievement  of  a  very  high  level  of  integration  and  reliability 
as  well.  Certainly  any  electronic  system  should  use  this  technology. 

Another  example  of  electronic  integration  is  communications  using  a 
single  channel  to  carry  multiple  signals  by  using  different  frequencies  and 
macchlng  encoders  and  decoders.  This  approach  is  also  adaptable  in  the  add¬ 
on  design  mode  in  which  existing  wiring  is  used  to  provide  additional  comnuni- 
cation  functions.  In  the  building  Industry  the  normal  electrical  wiring  or 
telephone  wiring  is  now  being  used  to  carry  energy  management  control  signals 
Instead  of  using  separate  wiring  for  the  latter  purpose.  Here  materials, 
labor,  and  some  degree  of  complication  is  saved  by  this  communications  inte¬ 
gration.  However,  more  complex  equipment  is  needed  to  produce  and  interpret 
the  carrier  frequencies  and  a  failure  may  result  in  multiple  systems  becoming 
non-functional. 

The  achievement  In  Integration  obtained  in  electronic  chips  has  not  been 
matched  In  mechanical,  pneumatic,  or  hydraulic  equipment  and  these  kinds  of 
components  have  therefore  become  the  limiting  factors,  with  respect  to  size, 
weight,  and  reliability  of  systems.  However,  that  is  not  to  say  that  non¬ 
electronic  systems  cannot  be  physically  integrated.  For  example,  if  a  pneu¬ 
matic  control  system  requires  a  pressure  source, it  may  be  possible  to  design 
the  system  such  that  all  of  the  control  functions  operate  from  only  one  pres¬ 
sure  source.  In  the  add-on  design  problem  if  a  new  control  modality  is  re¬ 
quired,  the  existing  pressure  source  may  be  of  adequate  capacity  to  support 
the  pre-existing  and  the  new  control  functions,  and  therefore  the  addition  of 
a  new  pressure  source  would  not  be  required.  If  the  existing  pressure  source 
was  not  of  adequate  capacity.  It  could  be  replaced  by  a  single  new  pressure 
source  of  sufficient  capacity  to  provide  both  the  old  and  the  new  functions 
as  opposed  to  adding  a  second  pressure  source  to  serve  only  the  new  need. 


The  seemingly  inevitable  tradeoffs  again  occur.  The  single  pressure  source 
Is  likely  to  be  smaller  and  lighter  than  two  pressure  sources.  However,  if 
it  fails,  all  control  functions  would  be  lost  whereas  if  one  of  two  pressure 
sources  failed,  only  part  of  the  control  functions  would  be  lost. 

Physiological  systems  also  provide  numerous  examples  of  physical  inte¬ 
gration  in  the  sense  that  many  organs  exhibit  multiple  and.  In  some  cases, 
unrelated  functions.  The  respiratory  system,  for  example,  serves  to  exchange 
gas  between  the  physiological  system  and  the  environment.  It  also  serves  to 
eliminate  water  vapor  and  as  a  heat  exchanger.  Furthermore, the  respiratory 
system  "powers"  the  function  of  speech.  Likewise  other  organs  of  the  physio¬ 
logical  system  have  a  lengthy  list  of  functions,  and  in  many  cases  there  are 
probably  additional  functions  which  have  not  yet  been  Identified. 

In  addition  to  the  large  number  of  functions  of  physiological  organ 
systems,  it  is  also  noteworthy  that  these  functions  occur  and  are  controlled 
at  a  very  small  size  scale.  The  specialized  collections  of  these  small  ele¬ 
ments  exhibit  a  combination  of  complex  behavior  In  a  package  size  which  is 
well  beyond  current  man-made  systems.  Although  they  may  be  the  premier 
examples  of  Integrated  systems,  they  are  none-the-less  just  examples.  However, 
as  examples,  they  may  Illustrate  certain  specific  techniques  for  achieving 
sophisticated  function  in  small  packages.  The  concept  of  bionics  was  based 
on  this  notion  that  observing  physiological  system  function  would  provide 
guidance  to  the  designers  of  man-made  systems  with  respect  to  methods  for 
achieving  efficient,  small,  and  yet  sophisticated  and  reliable  system  func¬ 
tions.  Unfortunately  this  approach  has  been  stymied  by  the  Incomplete  know¬ 
ledge  of  the  details  of  physiological  function  and  control,  and  relatively 
few  man-made  systems  have  been  successfully  designed  by  utilizing  or  mlmiclng 
physiological  system  function.  However,  some  observations  are  perhaps  of 
value  as  general  guidance. 

Higher  level  systems  have  Identified  subunits,  each  with  Its  own  struc¬ 
ture  and  functions.  Subunits  have  further  subunits,  and  the  Interrelation¬ 
ships  at  these  lower  anatomical  levels  can  be  as  complex  as  between  the  lar¬ 
ger  units  themselves.  These  subunits  have  a  very  high  degree  of  communica¬ 
tion  and  Interaction  between  them,  and  It  Is  probable  that  no  subunit  acts 
totally  Independently  of  others.  In  some  cases,  there  are  parallel  controls 
while  In  others  there  are  series  controls.  In  some  cases,  multiple  path 
control  functions  are  accomplished  by  additive  effects  while  in  others  con¬ 
trol  signals  are  generally  subtractive.  Subtractive  control  provides  a  high 
degree  of  fine  tuning,  maintenance  of  homeostasis,  and  the  potential  for  rapid 
responses.  There  are  both  local  controls  and  system-wide  controls.  There 
are  redundant  systems  as  well  as  unitary  ones.  Despite  these  complex  control 
methodol ogles  specialization  is  such  that  some  organs  can  be  surgically  re¬ 
placed  and  the  new  unit  can  function,  although  perhaps  not  as  well  as  the 
original,  without  the  restoration  of  all  of  the  normal  control  modalities. 

It  Is  debatable  whether  all  physiological  subsystems  have  individually 
achieved  optimum  adaptation  or  If  only  the  combination  of  subsystems  has 
reached  an  adaptive  status  quo.  In  fact  since  many  physiological  systems  are 
Imperfect  and  subject  to  a  wide  array  of  negative  external  influences,  it 
could  be  argued  that  only  limited  adaptation  has  ever  been  achieved.  Adap¬ 
tation  has  resulted  In  increased  complexity  and  specialization  of  some  organs, 
and  the  elimination  or  partial  elimination  of  other  organs  and  structures. 


Adaptation  has  also  been  to  only  a  more-or-less  specific  environment  and  to 
more-or-less  specific  behavior  patterns.  For  many  species, alteration  In  the 
environment  or  altered  performance  demands  on  the  species  will  result  In 
disfunction  or  death. 

Physiological  system  development  has  proceeded  from  the  smallest  size 
scale  up  to  the  organ  level,  and  with  the  simultaneous  Integration  of  the 
organ  Into  the  total  system.  This  presents  an  interesting  contrast  to  man¬ 
made  systems  In  which  functional  need  Is  defined  first.  Then  down-scale 
design  defines  the  components  necessary  to  achieve  the  function,  and  up¬ 
scale  design  defines  the  Interfacing  of  the  system  Into  Its  surroundings. 

From  the  physiological  systems  perspective  this  represents  starting  the  de¬ 
sign  In  the  middle.  The  achievement  of  comparable  Integration  would  likely 
require  the  Identification  of  all  functional  requirements  first  so  that  the 
downscale  search  for  design  solutions  can  occur  simultaneously  and  consis¬ 
tently  with  the  requirements  of  the  whole.  In  man-made  systems  the  defini¬ 
tion  of  a  new  functional  requirement  for  an  already  existing  system  may 
result  In  the  search  for  a  way  to  fit  It  In  or  add  it  on  rather  that  result 
In  Its  Integration  Into  the  design.  In  comparison  there  would  not  seem  to  be 
any  natural  examples  of  add-on  design;  Instead  existing  systems  are  modified 
to  achieve  new  functions.  In  fact,  most,  If  not  all,  sudden  system  mutations 
tend  to  be  harmful  and  destructive  to  the  Individual. 


APPLICATION  OF  INTEGRATION  TO  LIFE 
SUPPORT  SYSTEMS 

The  definition  of  Integration  given  earlier  Is  the  process  of  combining 
tasks  or  system  hardware  so  as  to  optimize  a  system  design  with  respect  to 
preselected  parameters.  In  the  case  of  aircrew  life  support  systems  relevant 
task  parameters  must  measure  the  number  and  kinds  of  tasks  that  the  aircrew 
member  can  adequately  perform  under  actual  operational  conditions.  System 
hardware  Integration  will  generally  be  aimed  at  reducing  the  weight  and  bulk 
of  the  equipment  In  order  to  reduce  the  burden  on  the  operator's  performance. 
These  burdens  may  Include  fatigue,  heat  stress,  discomfort.  Interference  with 
motion,  and  possible  risk  of  Injury  from  the  equipment  under  emergency  condi¬ 
tions. 

As  noted  earlier,  the  perceived  need  for  integration  Is  based  on  the 
observation  that  the  existing  systems  are  burdensome  In  a  variety  of  ways. 
Important  questions  here  are  what  Is  meant  by  burdensome  and  how  did  a  system 
perceived  to  be  burdensome  become  operational. 

A  judgment  that  the  system  Is  burdensome  means  that  it  either  Is  actual¬ 
ly  unacceptable  In  that  the  functional  requirements  of  the  man-machine  system 
are  not  met,  or  it  means  that  the  functional  requirements  are  met,  but  only 
In  some  marginal  way.  In  the  latter  case,  dissatisfaction  may  Imply  that  an 
alternative,  although  perhaps  unknown,  design  would  better  meet  the  require¬ 
ments.  However,  It  Is  rarely  possible  to  prove  that  the  lightest,  smallest, 
etc.  design  has  been  achieved.  Rather  a  design  has  been  achieved  that  meets 
the  stated  requirements  of  the  lightest,  smallest,  etc.  of  several  design 
alternatives  that  meet  the  requirements,  and  It  has  been  accepted. 


If  the  system  does  not  meet  the  functional  requi rements ,  then  the 
design  process  must  have  failed  somewhere  along  the  path  from  objectives  to 
acceptance  testing. 

.  Several  .possibilities  are: 

i  * 

).  The  design  requirements  and  constraints  were  Inadequately  or  Incor¬ 
rectly  'stated. 

2.  The  desj<Jndrs  failed  to  recognize  or  meet  the  stated  design  require¬ 
ments  or  constraints. 

3.  The  test  procedures  to  assure  compliance  with  the  design  require¬ 
ments  and  constraints  were  Inadequate. 

4.  The  new  subsystem  came  on-line  more-or-less  simultaneously  with 
other  new  subsystems  such  that  the  cumulative  effect  caused  the 
unacceptability. 

5.  The  burdensomeness  of  the  system  has  been  accepted  as  a  tradeoff  In 
the  partial  satisfaction  of  the  requirements  and/or  the  constraints. 

If  tlie  modified  system  does  meet  the  functional  requirements  and  con¬ 
straints  and  test  procedures,  then  the  judgment  that  the  system  Is  burdensome 
iminies  that  tMT drlglnalspeclfications  allowed  a  burdensome  system  as  a 
solution  to  the  problem.  Tints  the  fault  again  lies  with  the  specifications 
and  tests  for  the  origin*]  design. 

The  conclusion  herd  fs  that  while  Integration  Is  a  design  objective,  it 
does  not  necdsiarlly  yield  unburdensome  equipment  and  that  the  key  to  good 
design  Is  the  $drrect  original  specifications  of  the  system  and  appropriate 
test  and  related  management  procedures. 


RELATIONSHIP  OF  INTEGRATION  TO 
PHASES  OF  EQUIPMENT  DEVELOPMENT 


A  basic  question  posed  at  the  Inception  of  this  project  was  to  relate 
the  observations  made  about  Integration  to  the  stages  of  the  existing 
research  and  development  process.  These  progressive  phases  are  6.1  Research, 
6.2  Exploratory  Development,  6.3  Advanced  Development,  and  6.4  Engineering 
Development.  The  relevant  questions  are:  When  can  integration  be  considered? 
When  must  Integration  be  considered  to  achieve  the  objectives  of  integrated 
systems  design?  Recognizing  that  add-on  design  is  likely  to  continue  to  be 
used,  the  same  two  questions  can  be  asked  with  respect  to  add-on  requirements. 

Basic  research,  categorized  as  6.1  Research,  Identifies  and  develops  a 
basic  knowledge  base  without  consideration  of  any  clear  or  direct  application 
and  often  without  including  any  hardware  considerations.  Therefore,  the 
principles  of  integration  and  effective  add-on  are  generally  not  relevant  as 
applied  to  increased  understanding  of  natural  phenomena  In  science  and  engi¬ 
neering.  An  exception  here  would  be  research  expressly  aimed  at  determining 
exactly  how  a  physiological  subsystem  achieves  both  Its  individual  function 
and  coordination  with  the  whole. 

Applied  research,  categorized  as  6.2  Exploratory  Development,  attempts 
to  explore  and  develop  a  technological  base  through  the  application  of  engi¬ 
neering  principles  and  basic  knowledge  bases.  This  category  also  evaluates 
the  practicality  and  feasibility  of  technological  bases  toward  the  solutions 
of  specific  military  problems,  but  excludes  major  development.  Integration 
principles  should  begin  to  be  applied  in  exploratory  development  systems,  at 
least  at  the  subsystem  level.  The  development  of  a  sound  technological  base 
is  normally  initiated  by  the  conceptual  phase  during  which  problems  and  needs 
are  studied.  This  phase  has  limitations  imposed  by  the  available  technical 
knowledge  and  the  changing  requirements  which  are  often  initially  incomplete 
or  ill  defined,  resulting  in  successive  iterations.  This  iteration  process 
facilitates  the  Implementation  of  Integration. 

The  potential  relationship  of  hardware  or  tasks  under  development  at 
this  level  to  the  existing  system  and  Its  constraints  needs  only  minimal  con¬ 
sideration  since  the  objective  at  this  phase  is  generally  demonstration  of 
subsystem  technical  feasibility  and  the  testing  of  concepts.  However,  it 
would  not  be  Inappropriate  at  this  level  for  the  Investigators  to  be  know¬ 
ledgeable  on  the  possible  future  relationship  of  their  project  to  the  whole 
system. 

After  a  technological  base  has  been  achieved,  projects  are  moved  into 
the  next  phase,  6.3  Advanced  Development.  Within  this  category,  technologies 
are  combined  and  hardware  Is  created  for  experimental  or  operational  tests. 

It  Is  at  the  transition  from  6.2  to  6.3  and  within  6.3  that  integration  Is 
generally  needed  as  part  of  the  hardware  development.  In  particular,  the 
combination  of  technologies,  either  new  with  existing  or  new  with  new,  can 
be  achieved  at  this  phase  so  that  necessary  future  combination  of  equipment 
can  be  achieved  at  the  test  level.  Furthermore,  equipment  must  be  configured 
In  such  a  way  that  at  least  feasibility  for  actual  future  implementation  can 
be  demonstrated. 


Technologies  or  combinations  of  technologies  proven  In  6.3  must  be  ulti¬ 
mately  combined  with  the  existing  system.  To  achieve  an  adequate  level  of 
Integration  It  would  often  be  necessary  for  the  entire  existing  system,  or 
significant  parts  of  It,  rather  than  just  the  new  technology  Itself,  to  move 
Into  the  next  phase*  6.4  Engineering  Development,  which  Is  the  last  develop¬ 
ment.  category.  Even  a.  potential;  add-on  component  cannot  proceed  to  6.4  by 
Itself  since  Its  Independent  further  development  Is  contrary  to  the  goals  of 
Integrated  system  development. 

,  From  6.4  systems  emerge  readyr for  service  use,  and  generally  only  coarse 
Interfacing  requirements^  can-'  be  maintained  under  the  concepts  of  conflgura- 
*  tlon  control  and  configuration  management.  Configuration  control  attempts  to 

prevent  equipment  Incompatibility*  primarily  by  a  codified  system  of  check¬ 
offs  and  approvals,  although  industry  bemoans  excessive,  unnecessary,  and 
costly  configuration  control.  Configuration  management  attempts  to  solve 
this  problem  by  controlling, and  clearly  defining  the  baseline  configuration 
of  the  equipment  at  each" stafoe  of  final  development.  This  control  makes  It 
difficult  to  achieve  further  Integration  and  add-on  Interfacing  rather  than 
Integration  Is  normally  performed  since  Integration  would  generally  drive  up 
the  apparent  cost  and  compiiexity  of  the  subsystem  project.  Thus  at  6.4  It 
is  too  late  to  achieve.  Integration  If  only  the  new  subsystem  Is  brought  into 
this  level.  Moreover,  In  general ,  a  number  of  different  subsystems  may  be 
at  6.4  simultaneously  In  separate  projects,  all  of  which  are  to  be  eventually 
Interfaced  with  the  fixed  portions  of  the  existing  system. 

This  analysis  suggest ‘that  major  decision  making  with  respect  to  inte¬ 
gration  of  new  subsystems'  trite  the  existing  system  needs  to  be  made  between 
6.3  and  6.4,  since  within  6.4  it  is  too  late.  These  decisions  begin  with 
acceptance  of  the  need  fbKthre  technology  developed  in  6.3.  Consideration 
must  also  be  given  to  the  relationship  of  this  technology  both  functionally 
and  structurally  to  existing  technology,  to  other  technology  emerging  from 
6.3,  and  perhaps  to  promising  technologies  in  6.2  that  would  be  worth  waiting 
for.  The  major  decision,  then  occurs which  Is  to  select  all  of  the  system 
subsystems  and  components  that  will  require  simultaneous  engineering  redevel¬ 
opment  and  to  define  a  new  project  such  that  integration  will  be  achieved. 

In  summary, Integf atiorr  muft  begin  in  6.2,  must  be  given  major  consider¬ 
ation  in  6.3,  and  a  crltlthlly^ Important  new  control  step  Is  needed  between 
6.3  and  6.4.  ~r 


RULES  AND  LAWS  OF 
irfTE6RATI0N 

I.  General 

1.  An  Integrated  system  Is  one  In  which  tasks  and/or  system  hardware 
have  been  combined  so  as  to  optimize  a  system  design  with  respect  to 
preselected  parameters. 

2.  The  critical  parameters  of  a  system  and  the  permissible  values  of 
those  parameters  must  be  known  and  specified  as  part  of  the  design 
constraints. 

3.  Any  system,  no  matter  how  well  designed  and  Integrated,  can  only 
perform  correctly  under  a  finite  set  of  operational  conditions. 
Therefore  the  prescribed  set  of  such  conditions  must  be  known  in 
advance  of  system  design  and  must  be  maintained  and  updated  as  a 
single  source  document. 

4.  The  occurrence  of  new  system  requirements,  or  new  useful  technologies, 
requires  the  complete  re-evaluation  of  the  system  definition  and 
subsequent  redesign  of  the  system  In  order  to  maintain  system  perfor¬ 
mance. 

5.  Modularization  and  add-on  can  be  the  antithesis  of  system  integration 
In  that  the  resultant  division  of  the  design  task  reduces  the  oppor¬ 
tunities  to  achieve  the  required  combinations  of  tasks  and  hardware. 

6.  The  difficulty  of  achieving  a  well-integrated  system  Increases  sharp¬ 
ly  with  the  number  of  subsystems  and/or  subsystem  contractors  and  the 
time  span  over  which  the  system  is  developed  and  used. 

7.  System  constraints  (e.g.,  weight)  should  be  viewed  as  absolute  permis¬ 
sible  levels  and  alternative  designs  sought  such  that  the  deviation 
from  the  permissible  level  Is  maximized. 

8.  The  word  "Integration1*  should  be  restricted  to  usage  consistent  with 
the  definition  given  here  so  that  the  process  of  adding  or  modifying 

a  system  is  not  called  Integration  If  It  does  not  meet  the  definition. 

II.  With  Respect  to  Add-ons 

1.  In  solving  one  problem  through  the  use  of  added  equipment,  there  must 
be  assurance  that  the  resultant  new  system  still  meets  all  of  the 
previous  performance  and  constraint  requirements. 

2.  Every  modification  or  addition  to  a  system  has  the  potential  to  alter 
the  overall  capabilities  and  limitations  of  the  system,  often  detri¬ 
mentally. 

3.  Every  proposed  add-on  must  be  accompanied  by  an  analysis  of  Its  impact 
on  the  overall  system  and  each  of  Its  functions. 


18 


V*  r-  4  '  V  • 


4.  Whenever  new  requirements  occur,  consideration  must  be  given  to 
modifying  the  existing  system,  combining  functions  and  subsystems, 
and  deleting  subsystems  before  proposing  an  add-on. 

5.  Addition  of  new  functions  to  a  system  requires  the  existence  of  a 
comprehensive,  current  design  and  constraint  specification  for  the  as 
is  system. 

III.  With  Respect  to  Management 

.  v  r» 

1.  Authority  must  exist  which  can  declare  a  system  as  frozen  with 
respect  to  additional  add-ons  or  modifications  pending  total  redesign. 

2.  System  management  must  control  not  only  the  existing  and  near-term 
add-ons  or  modifications,  but  also  be  aware  of  and  project  other 
developments  which  will  affect  the  system  in  the  future. 

3.  Development  contractors  must  be  made  aware  of  and  demonstrate  under¬ 
standing  of  the  existing  system  and  must  document  the  projected  inte¬ 
gration  of  their  project  Into  the  existing  system. 

4.  Critically  important  management  decisions  must  occur  when  useful 
technologies  have  been  proven  and  become  candidates  for  inclusion  in 
the  existing  system. 

5.  Bureaucratic  structures  aimed  at  achieving  system  compatibility  do 
not  necessarily  achieve  their  objective. 

IV.  With  Respect  to  Life  Support  Equipment 

1.  The  system  must  be  built  around  the  total  spectrum  of  needs  of  the 
user  and  this  spectrum  must  be  known. 

2.  User  effectiveness  will  depend  on  (1)  the  baseline  capabilities  of 
the  user,  (2)  the  task  requirements  placed  on  the  user,  (3)  the  envi¬ 
ronment  of  use,  and  (4)  the  design  of  the  equipment  being  used.  The 
first  three  require  detailed  knowledge  and  documentation  before  ra¬ 
tional  design  can  proceed. 

3.  In  protecting  the  user  from  one  hazard,  no  new  unacceptable  hazards 
should  be  created  and  no  Interference  with  other  hazard  preventative 
measures  or  systems  should  occur.  Therefore  a  comprehensive,  ongoing 
system  safety  analysis  must  exist. 

4.  A  complete  and  up-to-date  operational  scenario  is  required  to  provide 
a  test  framework  for  the  life  support  equipment. 

5.  The  relative  risks  associated  with  hazards  must  be  assessed  to  make 
inevitable  trade-offs  decisions  between  complexity  and  function. 
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INTEGRATED  ENGINEERING  DESIGN  CHECKLIST 


Oo  I  have  a  clear  definition  of  the  design  objectives? 

Do  I  have  a  clear  definition  of  the  design  task  and  hardware  constraints? 

Do  I  need  to  further  understand  the  systems  this  design  will  Interact  with? 

In  setting  tasks  for  the  operator,  do  I  know  what  other  tasks  the  operator 
has  and  any  necessary  Information  on  the  ability  of  the  operator  to  do  the 
new  assigned  task  under  operational  conditions? 

Do  the  constraints  provide  this  knowledge? 

In  adding  hardware  to  the  system,  do  I  understand  all  the  effects  this  hard¬ 
ware  will  have  on  the  system  and  the  operator? 

Do  the  constraints  provide  this  knowledge? 

Is  there  available  hardware  In  the  system  that  can  be  used  to  achieve  or 
partially  achieve  the  new  design  objectives? 

Did  I  use  the  available  hardware? 

If  not,  why? 

In  providing  new  hardware  components,  have  I  made  maximum  use  of  these  compo 
nents  so  as  to  avoid  unnecessary  hardware  additions  to  the  system? 

If  not,  why? 


CONCLUSIONS  AND 
FURTHER  RESEARCH  NEEDS 


The  objective  of  this  project  was  to  identify,  under  the  term  "integra¬ 
tion,"  those  rules, guidelines, and  management  processes  which  when  followed 
would  result  in  optimal  system  performance  and  the  avoidance  of  certain 
types  of  problems  which  presently  exist  in  aircrew  life  support  equipment. 

The  conclusions  of  the  analysis  presented  here  are: 

1.  The  occurrence  of  burdensome  or  otherwise  problematical  equipment 
is  more  a  result  of  poorly  defined  design  constraints  rather  than 
lack  of  integration  as  defined  here.  Therefore  lack  of  integration 
is  not  necessarily  the  cause  of  equipment  problems  nor  will  integra¬ 
tion  necessarily  eleviate  them. 

2.  Integration,  the  combining  of  tasks  or  system  hardware  so  as  to  op¬ 
timize  a  system  design  with  respect  to  preselected  parameters,  requi¬ 
res  a  detailed  specification  of  the  critical  parameters  and  suffi¬ 
cient  design  alternatives  such  that  the  optimum  design  can  be  selec¬ 
ted.  This,  in  general,  would  require  an  approach  in  which  several 
designs  which  meet  the  functional  requirements  are  developed  and  at 
least  conceptually  tested  against  the  constraints  and  parameters 
requiring  optimization.  Suitable  methods  or  types  of  integration 
depend  on  the  type  of  system  being  designed  (e.g.,  electrical, 
mechanical,  hydraulic,  etc.)  and  the  relevant  design  rule  is  simply 
to  minimize  the  number  and  types  of  tasks  and/or  the  amount  of  hard¬ 
ware  necessary  to  achieve  the  functional  design  objectives. 

3.  Both  technical  and  managerial  research,  development,  and  implemen¬ 
tation  control  is  necessary  to  (a)  properly  define  subsystem  design 
constraints,  (b)  identify  existing  subsystems  that  can  or  must  be 
redesigned  to  acconmodate  other  new  subsystems,  and  (c)  test  any 
resultant  system  for  overall  compliance  with  total  function  and 
total  constraints. 

This  project  has  identified  a  number  of  potentially  useful  research 
areas  which  could  be  pursued  in  order  to  enhance  system  integration  achieve¬ 
ment,  in  general,  and  specifically  with  respect  to  life  support  equipment. 
These  are: 

1.  Continued  research  on  the  effect  of  equipment  mounted  on  or  worn  by 
the  user  on  system  and  user  performance  and  the  establishment  of 
appropriate  limits  for  tasks  and  equipment. 

2.  Development  of  Improved  design  criteria  for  the  specific  area  of 
user  mounted,  worn  or  used  equipment. 

3.  Development  of  a  computer-based  task  simulator  against  which  new 
tasks  can  be  tested  for  operational  compatibility. 


4.  Development  of  a  comprehensive  operations  simulator  to  provide  a 
test  framework  for  task  and/or  hardware  additions. 

5.  In-depth  study  of  existing  systems  to  identify  system  configuration 
problems,  prioritize  redesign  efforts  and  provide  specific  illus¬ 
trations  and  applications  of  integration  concepts. 

6.  In-depth  study  of  the  existing  Air  Force  management  structure  with 
respect  to  equipment  research,  development,  integration  and  config¬ 
uration  control  to  identify  needed  changes  or  effectiveness  enhance¬ 
ment. 

7.  Study  of  the  potential  utility  of  modern  decision  support  theory  and 
its  application  to  the  critical  technical  and  managerial  issues  in 
life  support  system  design  and  control. 

The  latter  is  a  subject  which  is  receiving  considerable  attention  in  our 
Industrial  Engineering  Department  and  which  has  significant  potential  with 
respect  to  some  of  the  identified  needs. 
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